home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-ospf-guidelines-frn-00.txt < prev    next >
Text File  |  1993-05-03  |  16KB  |  385 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.      Network Working Group                                 O. S. deSouza
  8.      Internet Draft                                      M. A. Rodrigues
  9.                                                   AT&T Bell Laboratories
  10.                                                           April 30, 1993
  11.  
  12.                          Guidelines for Running OSPF
  13.                           Over Frame Relay Networks
  14.  
  15.  
  16.  
  17.      Status of this Memo
  18.  
  19.      This document is an Internet Draft. Internet Drafts are working
  20.      documents of the Internet Engineering Task Force (IETF), its Areas,
  21.      and its Working Groups. Note that other groups may also distribute
  22.      working documents as Internet Drafts.
  23.  
  24.      Internet Drafts are draft documents valid for a maximum of six
  25.      months. Internet Drafts may be updated, replaced, or obsoleted by
  26.      other documents at any time. It is not appropriate to use Internet
  27.      Drafts as reference material or to cite them other than as a
  28.      "working draft" or "work in progress." Please check the 1id-
  29.      abstracts.txt listing contained in the internet-drafts Shadow
  30.      Directories on nic.ddn.mil, ds.internic.net, nic.nordu.net,
  31.      ftp.nisc.sri.com, or munnari.oz.au to learn the current status of
  32.      any Internet Draft.
  33.  
  34.      This memo does not specify a standard for the Internet community.
  35.      Please send comments to the authors.
  36.  
  37.  
  38.      Abstract
  39.  
  40.      This memo specifies guidelines for implementors and users of the
  41.      Open Shortest Path First (OSPF) routing protocol to bring about
  42.      improvements in how the protocol runs over frame relay networks.
  43.      We show how to configure frame relay interfaces in a way that
  44.      obviates the "full-mesh" connectivity required by current OSPF
  45.      implementations. This allows for simpler, more economic network
  46.      designs.  These guidelines do not require any protocol changes;
  47.      they only provide recommendations for how OSPF should be
  48.      implemented and configured to use frame relay networks efficiently.
  49.  
  50.  
  51.      Acknowledgements
  52.  
  53.      This memo is the result of work done in the OSPF Working Group of
  54.      the IETF. Comments and contributions from several sources,
  55.      especially Fred Baker of ACC, John Moy of Proteon, and Bala
  56.      Rajagopalan of AT&T Bell Laboratories are included in this work.
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.      deSouza, Rodrigues       Expires 10/30/93                  [Page 1]
  64.  
  65.  
  66.  
  67.      Internet Draft         OSPF over Frame Relay         April 30, 1993
  68.  
  69.  
  70.  
  71.      1.  Introduction
  72.  
  73.      A frame relay (FR) network provides virtual circuits (VCs) to
  74.      interconnect attached devices. Each VC is uniquely identified at
  75.      each FR interface by a Data Link Connection Identifier (DLCI).  RFC
  76.      1294 specifies the encapsulation of multiprotocol traffic over FR
  77.      [1].  The devices on a FR network may either be fully
  78.      interconnected with a "mesh" of VCs, or partially interconnected.
  79.      OSPF characterizes FR networks as non-broadcast multiple access
  80.      (NBMA) because they can support more than two attached routers, but
  81.      do not have a broadcast capability [2].  Under the NBMA model, the
  82.      physical FR interface on a router corresponds to a single OSPF
  83.      interface through which the router is connected to one or more
  84.      neighbors on the FR network; all the neighboring routers must also
  85.      be directly connected to each other over the FR network.  Hence
  86.      OSPF implementations that use the NBMA model for FR do not work
  87.      when the routers are partially interconnected.  Further, the
  88.      topological representation of a multiple access network has each
  89.      attached router bi-directionally connected to the network vertex
  90.      with a single link metric assigned to the edge directed into the
  91.      vertex.
  92.  
  93.      We see that the NBMA model becomes more restrictive as the number
  94.      of routers connected to the network increases. First, the number of
  95.      VCs required for full-mesh connectivity increases quadratically
  96.      with the number of routers. Public FR services typically offer
  97.      performance guarantees for each VC provisioned by the service. This
  98.      means that real physical resources in the FR network are devoted to
  99.      each VC, and for this the customer eventually pays. The expense for
  100.      full-mesh connectivity thus grows quadratically with the number of
  101.      interconnected routers.  We need to build OSPF implementations that
  102.      allow for partial connectivity over FR.  Second, using a single
  103.      link metric (per TOS) for the FR interface does not allow OSPF to
  104.      weigh some VCs more heavily than others according to the
  105.      performance characteristics of each connection. To make efficient
  106.      use of the FR network resources, it should be possible to assign
  107.      different link metrics to different VCs.
  108.  
  109.      These limitations of the current OSPF model for FR become more
  110.      severe as the network size increases, and render FR technology less
  111.      cost effective than it could be for large networks. We propose
  112.      solutions to these problems that do not increase complexity by much
  113.      and do not require any changes to the OSPF protocol.
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.      deSouza, Rodrigues       Expires 10/30/93                  [Page 2]
  128.  
  129.  
  130.  
  131.      Internet Draft         OSPF over Frame Relay         April 30, 1993
  132.  
  133.  
  134.  
  135.      2.  Summary of Recommendations
  136.  
  137.      We propose expanding the general view of an OSPF interface to
  138.      account for its functional type (point-to-point, broadcast, NBMA)
  139.      rather than its physical type. In most instances, the physical
  140.      network can only serve one function and can only be defined as one
  141.      type of OSPF interface. For multiplexed interfaces such as FR
  142.      however, logical connections between routers can serve different
  143.      functions. Hence one VC on a FR interface can be viewed distintly
  144.      from other VCs on the same physical interface.  The solution
  145.      requires that OSPF be able to support logical interfaces (networks)
  146.      as well as physical interfaces.  Each logical network can be either
  147.      point-to-point, that is, a single VC, or NBMA, that is, a
  148.      collection of VCs.  It is not necessary to define new interface
  149.      types for logical networks, since the operation of the protocol
  150.      over logical point-to-point networks and logical NBMA networks
  151.      remains the same as for the corresponding physical networks. For
  152.      instance, logical point-to-point links could be numbered or
  153.      unnumbered.  It is only necessary for implementations to provide
  154.      the hooks that give users the ability to configure an individual VC
  155.      as a logical point-to-point network or a collection of VCs as a
  156.      logical NBMA network.
  157.  
  158.      The NBMA model does provide some economy in OSPF protocol
  159.      processing and overhead and is the recommended mode of operation
  160.      for small homogeneous networks. Other than the Designated Router
  161.      (DR) and the backup Designated Router (BDR), each router maintains
  162.      only two adjacencies, one each with the DR and BDR, regardless of
  163.      the size of the NBMA network.  When FR VCs are configured as
  164.      point-to-point links, a router would have many more adjacencies to
  165.      maintain, resulting in increased protocol overhead. If all VCs were
  166.      to have comparable performance characteristics as well, there may
  167.      not be compelling reasons to assign a different link metric to each
  168.      VC.
  169.  
  170.  
  171.      3.  Implementing OSPF over FR
  172.  
  173.      We recommend that OSPF router implementations be built so that
  174.      administrators can configure network layer interfaces that consist
  175.      of one or more FR VCs within a single physical interface.  Each
  176.      logical network interface could then be configured as the
  177.      appropriate type of OSPF interface, that is, point-to-point for a
  178.      single VC, or NBMA for a collection of VCs.  This capability would
  179.      allow a router to belong to one or more distinct IP subnets on a
  180.      single physical FR interface.  Thus, it is necessary that the
  181.      router be able to support multiple IP addresses on a single
  182.      physical FR interface.  As with physical NBMA networks, logical
  183.      NBMA networks must be full-mesh connected. While logical point-to-
  184.      point links can be either numbered or unnumbered, we show that it
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.      deSouza, Rodrigues       Expires 10/30/93                  [Page 3]
  192.  
  193.  
  194.  
  195.      Internet Draft         OSPF over Frame Relay         April 30, 1993
  196.  
  197.  
  198.  
  199.      is easier to implement routers to handle numbered logical point-
  200.      to-point links.
  201.  
  202.      3.1  Numbered Logical Interfaces
  203.  
  204.      The router administrator should be able to configure numbered
  205.      logical interfaces over FR as follows:
  206.  
  207.      STEP 1: Configure the physical interface specifying relevant
  208.              parameters such as the slot, connector, and port numbers,
  209.              physical frame format, encoding, and clock mode. In its
  210.              internal interface MIB [3], the router should create a new
  211.              ifEntry in the ifTable, assign the physical interface an
  212.              ifIndex, and increment the ifNumber by one.
  213.  
  214.      STEP 2: Configure the data-link layer over the interface,
  215.              specifying frame relay as the encapsulation method.
  216.              Parameters such as the DLCI encoding type and length,
  217.              maximum frame size, management interface (Annex D, LMI),
  218.              and address resolution procedure (manual, inverse ARP). If
  219.              a management interface is not supported, FR VCs must be
  220.              configured manually.
  221.  
  222.      STEP 3: Configure the IP network layer for the interface by
  223.              specifying the number of logical interfaces and the IP
  224.              address and subnet mask for each numbered logical
  225.              interface. Specify the VCs (by DLCI) associated with each
  226.              logical network interface if there is more than one.  If an
  227.              address resolution protocol such as  Inverse ARP [4] is
  228.              being used, it should suffice to specify a list of IP
  229.              addresses for the FR interface and have Inverse ARP create
  230.              the DLCI-IP address binding.
  231.  
  232.      STEP 4: Configure OSPF to run over each logical interface as
  233.              appropriate, specifying the necessary interface parameters
  234.              such as area ID, link metric, protocol timers and
  235.              intervals, DR priority, and list of neighbors (for the DR).
  236.              OSPF interfaces consisting of one VC can be treated as
  237.              point-to-point links while multi-VC OSPF interfaces are
  238.              treated as NBMA subnets. In its internal OSPF MIB [5], the
  239.              router should create additional entries in the ospfIfTable
  240.              each with the appropriate ospfIfType (nbma or
  241.              pointTopoint).
  242.  
  243.      3.2  Unnumbered Point-to-Point Logical Interfaces
  244.  
  245.      OSPF uses the IP address to instance each numbered interface.
  246.      However, since an unnumbered point-to-point link does not have an
  247.      IP address, the ifIndex from the interface MIB is used instead [5].
  248.      This is straightforward for a physical point-to-point network,
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.      deSouza, Rodrigues       Expires 10/30/93                  [Page 4]
  256.  
  257.  
  258.  
  259.      Internet Draft         OSPF over Frame Relay         April 30, 1993
  260.  
  261.  
  262.  
  263.      since the ifIndex is assigned when the interface is configured.
  264.      Logical interfaces over FR however, do not have distinct and unique
  265.      values for ifIndex. To allow OSPF to instance unnumbered logical
  266.      point-to-point links, it is necessary to assign each such link a
  267.      unique ifIndex in STEP 3 above. This could lead to some confusion
  268.      in the interfaces table since a new ifTable entry would have to be
  269.      created for each logical point-to-point link. This type of
  270.      departure from the standard practice of creating interface table
  271.      entries only for physical interfaces could be viewed as an
  272.      unnecessary complication.
  273.  
  274.      Alternatively, it is possible to build a private MIB that contains
  275.      data structures to instance unnumbered logical links. However,
  276.      making recommendations for the structure and use of such a private
  277.      MIB is beyond the scope of this work.  Even if unnumbered point-
  278.      to-point logical links were implemented in this manner, it would
  279.      still be necessary to allow a FR interface to be configured with
  280.      multiple IP addresses when a router is connected to multiple NBMA
  281.      subnets through a single physical interface.  Hence, while it is
  282.      possible to define unnumbered logical point-to-point links in OSPF,
  283.      we find this alternative less attractive than using numbered
  284.      logical point-to-point links.
  285.  
  286.  
  287.      4.  Using OSPF over FR
  288.  
  289.      The ability to configure distinct logical interfaces over FR gives
  290.      users a great deal of flexibility in designing FR networks for use
  291.      with OSPF. Because routers can be partially interconnected over FR,
  292.      it is possible to design networks more cost-effectively than
  293.      before. The issues to consider are the price/cost structure for VCs
  294.      (fixed, distance-sensitive, banded) and ports, performance
  295.      guarantees provided, traffic distribution (local, long-haul), and
  296.      protocol efficiency. We have mentioned that the NBMA model provides
  297.      some economy in OSPF protocol processing and overhead and is
  298.      recommended for small homogeneous networks. In general, users
  299.      should configure their networks to contain several small "NBMA
  300.      clusters," which are in turn interconnected by long-haul VCs. The
  301.      best choices for the number of routers in each cluster and the size
  302.      of the long-haul logical point-to-point links depends on the
  303.      factors mentioned above. If it is necessary to architect a more
  304.      "flat" network, the ability to assign different link metrics to
  305.      different (groups of) VCs allows for greater efficiency in using FR
  306.      resources since VCs with better performance characteristics
  307.      (throughput, delay) could be assigned lower link metrics.
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.      deSouza, Rodrigues       Expires 10/30/93                  [Page 5]
  320.  
  321.  
  322.  
  323.      Internet Draft         OSPF over Frame Relay         April 30, 1993
  324.  
  325.  
  326.  
  327.      5.  Conclusion
  328.  
  329.      We have specified guidelines for OSPF implementors and users to
  330.      bring about improvements in how the protocol runs over frame relay
  331.      networks. These recommendations do not require any protocol changes
  332.      and allow for simpler, more efficient and cost-effective network
  333.      designs. We recommend that OSPF implementations be able to support
  334.      logical interfaces, each consisting of one or more virtual circuits
  335.      and used as numbered logical point-to-point links (one VC) or
  336.      logical NBMA networks (more than one VC). The current NBMA model
  337.      for frame relay should continue to be used for small homogeneous
  338.      networks consisting of a few routers.
  339.  
  340.  
  341.      6.  References
  342.  
  343.       1. T. Bradley, C. Brown, and A. Malis, "Multiprotocol Interconnect
  344.          over Frame Relay," Internet RFC 1294, January 1992.
  345.  
  346.       2. J. Moy, "OSPF Version 2," Internet RFC 1247, July 1991.
  347.  
  348.       3. K. McCloghrie and M. Rose, "Management Information Base for
  349.          Network Management of TCP/IP-based Internets: MIB-II," Internet
  350.          RFC 1213, March 1991.
  351.  
  352.       4. T. Bradley and C. Brown, "Inverse Address Resolution Protocol,"
  353.          Internet RFC 1293, January 1992.
  354.  
  355.       5. F. Baker and R. Coltun, "OSPF Version 2 Management Information
  356.          Base," Internet RFC 1252, August 1991.
  357.  
  358.  
  359.      7.  Authors' Addresses
  360.  
  361.      Osmund S. deSouza
  362.      AT&T Bell Laboratories
  363.      Room 1K-606
  364.      101 Crawfords Corner Road
  365.      Holmdel, NJ 07733
  366.      Email: osmund.desouza@att.com
  367.      Phone: (908) 949-1393
  368.  
  369.      Manoel A. Rodrigues
  370.      Room 1K-608
  371.      AT&T Bell Laboratories
  372.      101 Crawfords Corner Road
  373.      Holmdel, NJ 07733
  374.      Email: manoel.rodrigues@att.com
  375.      Phone: (908) 949-4655
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.      deSouza, Rodrigues       Expires 10/30/93                  [Page 6]
  384.  
  385.